home *** CD-ROM | disk | FTP | other *** search
/ EnigmA Amiga Run 1995 November / EnigmA AMIGA RUN 02 (1995)(G.R. Edizioni)(IT)[!][issue 1995-11][Skylink CD].iso / earcd / gfx / xfig_doc.lha / doc / TODO < prev    next >
Text File  |  1995-08-22  |  12KB  |  216 lines
  1. This file contains some possible things to do in future versions of xfig.
  2.  
  3. --------------------------------------------------------------------
  4. The following items would require a change to the Fig file protocol:
  5. --------------------------------------------------------------------
  6.  
  7. Allow different arrow head points (miter, round, bevel)
  8. Enhance all objects to have cap_style type for dotted lines
  9. Allow selecting linecap type for dotted lines for closed splines, boxes
  10.     and ellipses
  11. Allow user to set the tension in splines (change to compute_cp() in
  12.     d_intspline.c)
  13. Rotatable boxes - store width, height, upper-left corner and angle only?
  14. Allow multiple pages of figures
  15. Store page size with file
  16. Super/subscripts for text objects
  17.  
  18. ----------------------------------------------------------
  19. The following DON'T require a change to the file protocol:
  20. ----------------------------------------------------------
  21.  
  22. Automatic pan of canvas when drawing at an edge.
  23. Make a simple way to create quarter-circle and half-circle using arc
  24. Possibly use already allocated colors when importing GIF/XPM figures
  25.     (e.g. black, red, etc)
  26. Re-render EPS file (using gs) at new resolution when zooming LARGER
  27. Moving object when point_posn mode is on should first move object to closest
  28.     positioning grid position then allow movement from there.
  29.     Cancel should restore original coords.
  30. Confirm Delete All/Save Figure so user doesn't save over old file
  31.   e.g.    1) Work on existing file
  32.     2) save file
  33.     3) delete all to start new figure (filename is old one however)
  34.     4) save new figure should confirm save on old name
  35. Look in ../AppPlusS/XCC.c for code to allocate colors using any
  36.     valid visual/depth/colormap.
  37. When deleting (or adding) an arrowhead the object should be deleted
  38.     from the objects list so the redisplay can be done properly then
  39.     added back in to the list with the arrowhead deleted (or added)
  40. Bug: -pwidth/-pheight values ignored when switching Landscape/Portrait
  41.     This is hard to fix - what if the user wants -pwidth 11 and -pheight 5
  42.     and switches to Portrait mode.  Should the window be made 11 inches tall?
  43.     That is very tall for most displays.
  44. Use already allocated colors when importing GIF/XPM figures (e.g. black, red, etc)
  45. Option for smaller icons for mode panel for smaller screens
  46. Make <Shift>middle mouse button DELETE previous points just created during
  47.     create POLYobject/ARC/Ellipse etc.  That way, one may backup when
  48.     creating objects.
  49. Undo should undo multiple copy, rotate/copy etc.
  50. Should arrow size change in update mode when linewidth changes?
  51.     Easier method to set/change arrow size
  52. Mode to rotate objects using only the mouse (requires new mode button)
  53. Split/join two objects together (e.g. end of one line attached to the beginning
  54.     of another line to make single, new line).  This would only make sense
  55.     for lines/splines?
  56. Make zooming only rescale texts which are visible in the new zoom.  This may be
  57.     a problem because the bounding box of the text at the new size isn't
  58.     known until the font is rescaled.
  59. Make it smart about duplicate GIFs:
  60.     o Same GIFs on canvas use same bitmap[]
  61.       (each has its own pixmap in case different rotation, size etc)
  62.     o Thus, they all share the same colors
  63. Have "freehand" line drawing mode (draws points as long as mouse button
  64.     is down)
  65. Allow printing of grid in figure (actually fig2dev option)
  66. Make the rulers understand the real screen resolution according to the server
  67. Add the concept of "layers" for each depth.  That way a user may work on
  68.     certain layers at one time, masking out or overlaying the other layers
  69.     as desired.
  70. Create resource for "print" command (e.g. lp, lpr, whatever) which uses meta-
  71.     notation to place filename (e.g.  print_command: "lpr -P%p %f" where %p
  72.     is the printer string and %f is the filename)
  73. Allow option of vertically centering text either using the ascenders/descenders
  74.     (the current method) or not
  75. Allow vertically-aligned text
  76.   "top" would mean the insertion point specifies the line over the top of the
  77.         text
  78.   "middle" would mean that it specifies the midline of the text (I'm not
  79.         sure how this is defined, perhaps the average of top and base
  80.         or top and bottom.
  81.   "base" would mean the line under all letters which do not hang down.
  82.         For example, g and j extend below the baseline.
  83.   "bottom" would mean the time under the bottom of the text including
  84.         descenders.
  85. Have common edit popup for all four splines to allow conversion between all
  86. Save modified_flag before file operations and restore if undo used
  87. Change eps_bitmaps so that background is transparent; i.e. stipple (needs to
  88.     work in normal and reverse-video modes)
  89. Make popup windows come up so that they don't overlap the figure (if possible).
  90.     An edit popup window should at least not overlap the
  91.     object being edited (again only if possible).
  92. Use fill pattern (grey-shading) to mimic color objects on monochrome systems.
  93. Extend smart links to work for SCALE, MOVEPT and perhaps EDIT, UPDATE.
  94.     Could also extend them to work for arc-type links and for
  95.     ellipse/circle objects and objects inside compound objects.
  96.     Also, at the moment smart-links
  97.     only work for one end of a link if both ends of the link
  98.     happen to touch the object being operated on.  To fix this would
  99.     require changing the F_linkinfo structure to have left_endpt,
  100.     left_prevpt, right_endpt, right_prevpt fields instead of the current
  101.     endpt, prevpt and two_pts fields.
  102. Still need to think about how point positioning should be utilized with
  103.     many of the editing commands, e.g. if point positioning is set to
  104.     large grid and you are trying to move an object, should:
  105.     a) it be ignored, b) you can pick up an object anywhere but
  106.     you must put the 'pick-up' point back on a grid posn,
  107.     c) you have to pick up and put down objects at grid posns,
  108.     d) you can pick up and place an object anywhere but when you
  109.     place it, the point on the object closest the pickup point is
  110.     automatically rounded to the nearest grid posn, e) you can
  111.     pick up objects anywhere and movement is multiples of the grid size.
  112.     The current behaviour is c) and b) can be mimicked by changing the
  113.     point posn indicator mid-move.  It has the disadvantage that you
  114.     may not be able to pick up an object which isn't on the grid points.
  115.     I think e) is the next best but it won't let you mimick b).
  116. Use clipping rectangles in more places:
  117.     use the redisplay_* routines as necessary.
  118. Allow popup menus to be pinned?
  119. Make arcs use pw_curve to speed them up.
  120. Add bounding box to every F_object definition, useful for:
  121.     1) faster drawing of rubber objects
  122.     2) handling the selective redrawing of figures better after they become
  123.        the innocent victim during an expose or erasure of another object
  124. Things like pan/zoom/resize/iconify will still leave junk on the screen
  125.     or mess up the figure if you are in the middle of drawing it:
  126.     One solution is to call canvas_rightbut_proc whenever the
  127.     action_on flag is set and one of the above functions is called.
  128.     This forces the operation being performed to be cancelled - probably
  129.     not a good idea for panning - we might be trying to pan a little
  130.     bit to place the last point in a large object.
  131.     Another solution is to have a big case statement which performs
  132.     a single elastic draw of whatever object is being drawn/moved etc.
  133.     The function would need to be called before an iconify (or
  134.     whatever) and again after the operation was completed.  This
  135.     would allow drawing operations to be continued after window functions
  136.     had been performed.
  137.     A third solution is to use a canvas_elasticdraw_save parameter
  138.     instead of using a case statement - it would need to be set
  139.     prior to every elastic draw operation.
  140. Generalize align mode (like glue mode) to allow arbitrary tagged objects to be
  141.     aligned rather than just compounds.
  142. Some facility to provide better support for small screens.
  143.     e.g. scrollable mode button list or automatic resizing
  144.     to have several rows as needed.  A good test is to limit the total
  145.     space to 640x480 so that it is still useable on an IBM-PC VGA screen.
  146. Make a raise/lower depth feature:
  147.     the raise_ic icon is already in w_icons.c
  148. Make xfig understand depth better:
  149.     If you set the depth using the object edit panels, xfig will redraw
  150.     them correctly, however it would be nice if as you entered new filled
  151.     objects that they were automatically given an appropriate depth.
  152.     This would involve finding the depth of all overlapping (filled?)
  153.     objects and setting the depth to be one less.
  154.     What about support for negative depth values?
  155. Honor fractional text sizes (float).  Currently, xfig reads the size as float
  156.     but converts to integer internally.
  157. A 'gravity' mode whereby points placed by aiming and clicking are brought not
  158.     to the closest fiducial point of a figure, but to the closest continuous
  159.     point on the figure (applies only to circles, arcs, and straight lines),
  160.     taking into account constraints of angle (like manhattan constraint).
  161.     Example 1:  I click near the circumference of a circle.  The point is
  162.     placed exactly on the circumference, closest to where I clicked.
  163.     This is very useful for getting lines to touch circles exactly in points
  164.     other than the E, W, S, or N extreme.  Example 2:  I am in manhattan
  165.     constraint, and I click near a random-slope line.  The point is placed
  166.     on the line in the one place consistent with the manhattan constraint.
  167. Clean up array-place copy:
  168.     If y copies is set to 0, then xfig treats the x direction as the direction
  169.     of the copies.
  170.     If both are non-zero, the x and y are e-w and n-s, but the number of copies
  171.     can be fewer than x*y if the first copy is in a strange place.
  172.     If only y is set, it is like x, but the first copy (when y is 2) is not
  173.     drawn properly.
  174.  
  175. --------------------------------------------------------------------
  176. --------------------------------------------------------------------
  177. What really needs to be done is a major rework of the list structures used
  178.     to store xfig objects.  Here are some comments involving the change.
  179.  
  180. -------- note about restructuring xfig data structures -------------
  181. Rather than having a depth attribute for objects, you can use the order
  182. in which objects are entered to determine their depth:  later objects
  183. appear on the top.  A raise/lower depth operation would allow you to
  184. change the ordering.
  185.  
  186. The consequences to the current implementation of converting totally to this
  187. scheme are non-trivial.  Instead of having separate lists for each object
  188. type, you need to have a single list which has a union of all the different
  189. objects as its type.  This will require changes in many places in the code.
  190. At the moment there are many places where each of the lists are traversed
  191. separately.  In many cases the code can be simplified dramatically if there
  192. was only a single list.  For example, to perform a move on an object there
  193. are separate routines (one for each object type) to start/cancel/place the
  194. object.  You could replace this by a single routine for start/cancel and
  195. place which worked no matter what type you had.  (Who says you can't use
  196. object-orientation in C :-)).  Another advantage is that the current caching
  197. scheme for redrawing would no longer be needed (i.e. redrawing would be
  198. greatly simplified).  Also undo would become simpler (I think).
  199.  
  200. If we want to make a smooth transition from the current scheme to the
  201. one described above (and I do), here is how I propose we do it:
  202.  
  203. We need to change every direct access to the current lists to use functions.
  204. i.e. something like
  205.         for (a=objects.arc; a!=NULL; a=a->next) ...
  206. to be something like
  207.         for (a=first_arc(); a!=NULL; a=next_arc(a)) ...
  208.  
  209. At the moment these routines would be simple to implement.
  210. Once all occurrences had been changed, it would simply be a matter
  211. of changing the underlying list structure and changing the first_arc,
  212. next_arc routines.  Then as we had time we could replace whichever
  213. sets of six loops by a single loop which did
  214.         for (o=first_obj(); o!=NULL; o=next_obj(o)) ...
  215. -------- end of note about restructuring xfig data structures -------------
  216.